How we rolled out security keys at Twitter

Over the past year, we’ve accelerated efforts to increase the use of security keys to prevent phishing attacks. In June, we gave people the option to use multiple security keys to protect their Twitter accounts. We’ve also implemented security keys internally across our workforce to help prevent security incidents like the one Twitter suffered last year. This October, for #CybersecurityAwarenessMonth, we’re sharing some of our thoughts and takeaways from our efforts to deploy security keys internally at Twitter.

The rollout

As described in our previous post, security keys use the FIDO and WebAuthn security standards to provide phishing-resistent two-factor authentication (2FA). Security keys can differentiate legitimate sites from malicious ones and block phishing attempts that SMS 2FA or one-time password (OTP) verification codes would not. To deploy security keys internally at Twitter, we migrated from a variety of phishable 2FA methods to using security keys as our only supported 2FA method on internal systems. This process involved: 

1. Selecting a Security Key Model. We required a security key that would work across a range of devices. We selected a combination of the YubiKey 5 NFC and 5C NFC keys since these support both USB for laptops and NFC for Android or iOS mobile devices. 

2. Procuring and Distributing Keys. Once we selected a model, we had to purchase and ship security keys to over 5,500 individuals around the world. Yubico’s Enterprise Subscription and Delivery services, including its APIs, helped us automate the address-collection-to-shipping pipeline. Yubico provided a direct shipping solution within the US, Canada, and most of Europe. For the rest of our workforce, we bulk shipped keys to existing regional distribution partners, who provided last mile shipping.

3. Adding Security Key Support to Internal Systems. Most internal Twitter systems are behind a Single-Sign On (SSO) system. Our SSO provider already supported WebAuthn, and we enabled support for both security keys and platform authenticators, such as TouchID. By allowing, but not requiring, WebAuthn devices for 2FA, employees were able to enroll their security keys as they received them without losing access to systems ahead of the cutover date.

4. Registering and Enrolling Keys. Given the nature of WebAuthn, employees needed to self-enroll their keys once delivered. To aid them, we provided enrollment guidance illustrated with pictures and GIFs. Our IT team provided critical support along the way.

5. Flipping the Switch. Our final step was to disable legacy 2FA methods and mandate the use of security keys across our internal systems. We set a cutover date, which was shared with the entire company a month in advance. We reached ~90% security key enrollment by the deadline and were able to hit 100% within a month of cutting over, as folks returned from vacation or leave.

Lessons learned

In the end, we successfully migrated 100% of employee accounts from legacy 2FA methods to mandatory security key usage in under three months. We learned several important lessons along the way:

• Anticipate Global Shipping Challenges. COVID-19 deprived us of in-office distribution points. Instead, we had to ship keys to employees directly. This presented unique challenges: we had to collect up-to-date shipping information for a newly distributed workforce, deal with missing deliveries, and figure out how to validate that shipments weren’t tampered with. To work around these issues, we allowed employees to self-source security keys from regional vendors if shipments were lost or delayed. We also shared information on the timing and packaging of shipments with employees and pointed them to Yubico’s online verification tool to verify that their keys were legitimate.
• Leverage Built-In “Security Keys”. While hardware security keys are great for long-term use, they’re not the most convenient for authenticating on a day-to-day basis. Fortunately, a growing number of devices include built-in “security keys” that leverage the WebAuthn protocol to provide the same phishing-resistant benefits. These platform authenticators include Apple’s FaceID/TouchID, Windows Hello, and Android's built-in security key. We provided employees with directions for enrolling built-in platform authenticators, which proved popular both for their convenience and as a workaround for employees who faced shipping delays of their standalone security keys.
• Track Enrollment. The nature of security keys places the onus on employees to register them for use. At Twitter, we tackled this challenge by developing an internal dashboard that allowed employees to view their security key enrollment status across our various authentication systems. Managers could also view the enrollment status of their teams. We ultimately leveraged this dashboard system to verify which employees had completed all the steps necessary to log in after the cutover deadline. While some still failed to enroll their keys on time, our robust tracking and notification system allowed us to minimize this number and predict cutover impact.
• Anticipate Support Needs. Our security key migration required significant support from our internal IT teams. They were critical to helping individuals who failed to complete all the necessary registration steps by the deadline and provided 1:1 support for anyone having trouble getting their keys set up or who lost or broke their keys. We also had folks respond to security key questions on internal communication channels and work to rapidly socialize the use of security keys within the company.
• Encourage Wider Use. We made it clear that employees would be allowed to keep their security keys even after they leave the company. This allowed us to encourage employees to use their security keys to protect their personal accounts where supported. Better protection for employee personal accounts helps stop attackers from using those accounts to attack Twitter and wider usage of security keys promotes a more secure web for everyone.

The future of the ecosystem

Our rollout experience also highlighted a number of places where the security key ecosystem still needs to improve:

• Wider WebAuthn Support. While we’ve seen progress in systems adding support for security keys over the past several years, there are still systems where security keys do not work well. Desktop applications, for example, often leverage embedded web browsers to load web-based SSO login screens. Unfortunately, many of these embedded browser solutions lack support for the WebAuthn protocol, making it impossible to use security keys in these situations. Ideally, desktop applications would simply leverage the default system browser, all of which support security keys, for SSO login flows. This has additional benefits like ensuring password managers and existing SSO sessions can be leveraged as well.
• Key Rotation/Replacement. Today, replacing a security key is a significant usability challenge, requiring users to keep track of every service they’ve registered a security key with and individually visit each service, remove the old key, and add the new key. At Twitter, we issued all employees two keys to start, one primary and one backup. This ensures a fallback option in the event that the primary key is lost. We also used SSO to minimize the number of systems on which a user needs to register their keys. But we wish there were better ways to help users add and remove security keys across services. While there are efforts underway to simplify registering backup security keys, it’s still difficult for users to track where they have registered a specific security key or to replace keys when necessary. This remains an open challenge.
• Security Key UX. The usability of WebAuthn interfaces is key to their wider adoption. Services that support security keys should provide basic features like the ability to rename keys to make it easier for users to differentiate them. We’ve also found it helpful when platforms allow users to specify their default 2FA method so that users don’t have to click around to use their security key on each login.

Security keys are just one part of our ongoing effort to protect our employees and, in turn, everyone using Twitter. Overall, we’re very happy with the success of our internal security key rollout and with the phishing protections mandatory security key usage brings to our employees and internal systems. We hope to see industry-wide adoption of security keys, and we look forward to continuing to help mature the WebAuthn ecosystem for everyone.